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(57) Abstract 

The subject invention employs a system integrated 
fault-tree analysis (SIFTAN) whidi has the unique ability to 
detect all latent hardware and software design defects that 
could cause unanticipated critical failure of a complex sof- 
tware controlled electronic system. This new approach modi- 
fies and then integrates two exiting system analysis tech- 
niques-namely. hardware fault-tree analysis (HFTA) and sof- 
tware fault-tree analysis (SFTA). The resultant integrated 
technique is idendHed as SIFTAN for system integrated fault- 
tree analysis. Through its integrated hardware/soitware scope 
and its cridcal failure focus. SIFTAN has unique potential to 
solve the essential analytical limitation behind the software 
teiiabtlity problem. The system exceeds the scope of all cur- 
rent system analysis techniques by providing a system free 
from all potential cridcal speciiication hardware or software 
design errors. Hie system accomplishes the above-noted ob- 
jects by perfonnmg fault-tree analysis with respect to the con- 
tents of a dynamic ''stack of contradiction parameters" and 
then superimposing the modified hardware and software 
fault-trees onto each other. The superposition is accomplished 
by automatically branching f^om the software to a specified 
fault-tree hardware whenever hardware could result hi a criti- 
cal system output It is important to indicate that the SIFTAN 
sy^^ is applied with great advantages to early conceptual le- 
vels of system design in additi n to its certification of the fi- 
nal design implementation. 
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SYSTEM INTEGRATED FAULT-TREE ANALYSIS 
METHODS (SIFTAN) 
Background ef the Inventlcn 
This invention relates to system analysis methods 
regarding verification arid validation procedures and more 
particularly to a system analysis method which has the 
ability to detect latent hardware and software design defects 
which defects could cause \manticipated critical failures of 
digitally controlled systems. 

The following references provide an overview of the 
precedent software fault^tree analysis and hardware faults- 
tree analysis technologies Which are pertinent to the present 
system procedures as will be described. 

Harvey, Peter Randall. "Fault-tree Analysis of 
Software**. University of California, Thesis 1»82. 

Levenson, • Nancy 6. , and Janice L. Stolzy. "Safety - 
Analysis of Ada Programs Using Fault trees.** IEEE 
Transactions on Reliability Vol. R-32 No. 5 (Dec. 
1983), 470-S79. 

Mclntee, Capt. James H. "Soft Tree: Fault-tree 
Technique as Applied to Software Air Force 

Systems Command, Eglin Air Force Base, FL. Oct, 
1983. 

Taylor, J.R. **status of Software Safety 
verification and Validation Techniques." Lafayette, 
Indiana, USA. Notes prepared for SAFECOHP 82, Oct. 
1982. 

Taylor, J.R. "An Algorithm For Fault-Tree 
Construction • " IEEE Transactions on Reliability 
Vol. R«31, No. 2, (June 1982), 137-148. 



Taylor, J.R. ** Fault Tr e and Cause cons qu nee 
Analysis for Contr 1 Software Validation." 
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Roskilde, D nmarkt Rlso Hational Laboratoiry, 
January 1983. 

Taylor J.R. "Logical Validation of Safety and 
Control Systems specifications Against Plant 
Models." Roskilde, Denmark: Rise National 
Laboratory, Kay 1981. 

lis one can ascertain and as will be further 
described, there has been widespread invest^igations of system 
analysis techniques. 

As one can also ascertain, the prior art is replete 
with many examples of digitally controlled systems. Such 
systems extensively employ microprocessors, microcomputers, 
minicomputers and so on which may be distributed throughout 
the systoa which microprocessors contain extensive programs 
which operate to control system operation. Examples of such 
systems are telephone switching systems as well as many other 
systems utilized by the military such as digital automatic 
flight control systems and large scale digital communication 
systems in general. 

As one can ascertain, system reliability is a major 
risk area in the development of highly integrated and complex 
electronic systems such as the above-*noted systems as well as 
many systems which will be employed and are presently 
employed in defense electronics. The problems inherent in 
the design and utilization of such systems can be beat 
understood if they are segmented between system specification 
and software reliability, hardware reliability and the 
interaction of hardware and software failure. 

Errors in system specification and software are 
major current impediments to the achievement of system 
rcaiability. Latent specification and software failure 
present a serious risk to the successful development of such 
advanced and complicated systems. Many people who are 
familiar with such systems bellev th problem to be so 
sever that it rules ut the practicality of large conpl x 
sof'twar driven systems. According to this view, such 
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systems as digital automatic flight c ntrol systems, digital 
t lephone xchangea and digital communication systems vill 
inevitably be released with innvimerabl software problems 
which problems will escape detection during test and 
integration. These problems will only manifest themselves 
during system operation and only when a particular aspect of 
the system is accessed* These possible critical errors in 
software system specification or coding cannot be detected 
until the particular threat scenarios which exercise them are 
encoimtered. Thus, as one can ascertain, such software 
problems or *'bugs" can result in catastrophic system failure* 
This problem does not only apply to future 
generation advanced systems but is applicable to present 
systems. It is dear that software reliability is a major 
risk item with virtually all complicated digital system 
acquisition techniques. Over the past year, several 
Important techniques such as structured programming, top-^down 
design, and 'self-documenting code have been developed to- 
improve software reliability. These improvements however 
have not kept pace with the complexity of even current system 
designs* 

It is clear that even utilizing all of the 
currently available software design verification and 
validation methods, delivered systems are released to 
customers containing numerous software specification and 
coding errors. It is therefore quite common for the test and 
debugging phase of the system to consiuae more time in 
resources than the actual initial development and design. 

A related concern which will be discussed further 
is the fact that none of the current reliability analysis 
techniques can determine when the debugging phase is truly 
over. Essentially, what is meant by this is that in present 
reliability analysis techniques one cannot be assured that no 
undetected: mission critical specif ication or coding errors do 
not remain in tho design* The fundamental difficulty with 
software reliability is the fact that it is not possible to 
prov th corr ctness f most useful real time application 
software. There are simply too many possible p rmutatlons 
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and combinati ns f Input condltiona to allow on to trac 
the r suits of ach of th many sets of conditi ns through 
the software to determine system operation. In this respect 
a simple guidance and control or electronic warfare system 

S has at least 10^^ possible paths which are evailable through 
software routines. Even if each test could be generated, run 
and evaluated in a microsecond, it would take 30,000 years to 
test every conceivable path* There is no assurance that an 
untested softweure route, either alone or in combination with 

10 a hardware failure, will not result in a critical system 
failure* 

Although very small elementary programs can be 
mathematically proven, the proof of any realistic system 
application software is theoretically and, ipractically 

15 unfeasible. Since the correctness of realistic system 
software cannot be proven, the only alternative has been to 
test software in an effort to discover latent errors. While 
the state of the art in static and dynamic program testing 
can discover many software errors, since only a tiny fraction 

20 cf the possible sets of input conditions can be tested, there 
is no assurance given by these techniques that a considerable 
number of '*bugs^ does not remain. 

Attempts have been made in the prior art to utilize 
the statistical approach to develop various predictive models 

25 for software error idiich produce a software error "MIBP** 
(Mean Time Between Failure). However, due to the very great 
differences between the causes and the mechanisms of hardware 
and software failures, these attempts to carry over concepts 
developed for predicting hardware failure rates to the 

30 software domain are necessarily highly contentious. None of 
the statistical models ^ich have been proposed for 
prediction of software! failure rates has demonstrated general 
appl icability • 

In addition, these statistical models only attempt 

35 to derive the probability that no more than a set number of 
err rs remain in the design. They giv n assurance as to 
the criticality of thes residual errors. Essentially, as 
one can ascertain, the fundamental probl m with current 
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softvar verification and validation (V & V) technlqu s is 
that all possible Inputs cannot be tested for all posslbl 
paths. Unfortunately nany current software verification 
techniques focus on the detection of coding errors in saall 
program nodules. There is considerable evidence however that 
the majority of software "bugs'* are not coding errors but 
specification errors to which these testing techniques are 
completely insensitive. 

This fact also Impacts the value of N-version 
programialng as a software reliability tool since it Increases 
the likelihood of coasion mode failures. As systems become 
more highly integrated. It is the specification type of 
software errors which will increasingly predoainate. In 
regard to the above and in the arcM of hardware reliability, 
fault tolerance achieved through system reconfiguration upon 
real time detection of failure is a promising technical 
approach. One difficulty with system reconfiguration is that 
there must be an appropriate selection of which hardware 
resources will be protected from failure. It is generally 
not possible, desirable, or cost feasible to Implement 
sufficient backup sparing so that the effects of every, 
possible hardware failure can be masked through system 
reconfiguration^ 

The most obvious candidates for protection night 
not be the ones that best insure survivability. A great deal 
of effort and expense might be expended in application of 
siabassemblles or other major system resources only to have 
the potential for critical failure remain. This could 
easily result from a simple but critical element required for 
successful reconfiguration « For example, a power supply, a 
switching element or an interconnecting bus nay be 
overlooked. Zf such structures are overlooked and not 
protected from a single point failure, they can result in 
complete system failure. 

Alternatively, a transient failure of what was 
assumed to be a noncritlcal conpon€uit would caus the 
softwar to exercise a completely unanticipated path which 
r suits in a catastr phic system output • clearly, some 
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methodol gy Lb required that will xhaustively search for all 
of these possibilities and insur that th aission critical 
functions are protected by the system reconfiguration scheae. 

Finally, an additional important difficulty with 
currently employed techniques for determining software and 
hardware reliability is that both the system software and 
hardware are analyzed independently of each other. During a 
hardware reliability analysis (e«g. FMECA) Failure Hode 
Effects and Crlticality Analysis, it is falsely assumed that 
all software will function perfectly* During software 
verification and validation/ it is falsely assumed that the 
software will be executed in a hardware environment which is 
flawless. In actuality a hardware failure can cause totally 
unanticipated inputs to the software which might have 
disastrous consequences. 

Conversely^ a software error in the BIT (Buiit*Zn^ 
Test) or FDI (Fault Detection and Isolation) system or an 
error copied into all versions of redundant hardware can 
make system reconfiguration useless. The false 

disaseociation of software and hardware reliability analysis 
which currently prevails prevents the optimization of system 
reliability in those functions where failure could have the 
most critical effect. A much more accurate and fruitful 
approach would entail simultaneous analysis of the combined 
hardware and software operation of the system. Hence, as one 
can ascertain and in summation, current design and 
reliability analysis techniques permit the deployment of 
systems with undetermined potential for critical failure. 

This is particularly the case with regard to 
specification and software reliability. The intrinsic 
limitations of current techniques will result in the above- 
described situations and can be summarized as first the 
inability to cope with combinatorics of system failure 
potential in software driven systems; secondly, the extreme 
difficulty In analyzing the effects of multiple failures; and 
third the inability to analyze hardware and softwar failure 
int ractlons as~well as the inability to adequately determln 
system rec nflguration cov rage r quirements. 
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It Is th ref r an object f the pres nt invention 
to nploy a system analysis method vhich method has the 
unique ability to detect latent hardware and software design 
defects that could otherwise cause the unanticipated critical 
failure of a digitally controlled systea* 

Zt is a further object to provide system integrated 
fault-tree analysis (SZFTAN) methods which operates to 
modify and integrate existing system analysis techniqpies such 
as hardware fault-tree analysis (HFTA) and software fault- 
tree analysis (SFTA) to provide an integrated technique for 
verifying complicated digital system operation prior to 
releasing the system* 

Brief Description of the Pre ferred Embodiment 

A method of performing integrated fault-tree 
analysis on a digital software controlled system^ of the type 
employing hardware under the control of programmed software 
comprising the steps of predicting a critical system output * 
condition manifesting a top-level -event, determining from 
that predicted condition a set of prior system conditions 
which caused said event, modifying the system response to 
said event according to said determined set pf prior system 
conditions. 

Brief Description of the Flcmrea 
Figure 1 is a simple block diagram shoving the 
8XFTAN system and its gro%rth capability through modular 
enhancement « 

Figure 2 is a more detailed block diagram depicting 
system operation as indicated briefly in Fig. 1. 

Figure 3 consisting of Figs, A-C show a particular 
system example indicating the. operation of the system. 

Figure 4 consisting Figs* A-B show an another 
example of system operation* 

Figure 5 consisting of Figs. A-F show a detailed 
analysis of the system operation according to this invention 
in block-diagram form. 
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Figure 6 is a detailed diagraa shoving a. typical 
SIFTAN Integrated fault tree containing common program constructs. 

Figure 7 is a block diagram shoving a contradiction 
in software which prevents critical output* 

Figure S is a block diagraa shoving a contradiction 
in software which prevents a critical output but hardware 
failiure overrides the contradiction. 

Figure 9 is a block diagraa shoving the operation 
of this system in tracing the critical failu»« 

Figure 10 is a block diagram shoving the operation 
of this system in tracing a critical failure in regard to a 
threshold In analysis time. 

Figure 11 is a block diagram showing the system 
encountering an twanalyzable data structure* 

Figure 12 is a block diagram showing the logical 
events necessary to complete a hardware analysis* 

Figure 13 is a text format showing various data 
steps in determining system initialization* 

Figure 14 is a block diagram shoving requirement 
for separate analysis of OR'ed parameters in the 
contradiction stack according to this invention* 

petatle4 p^ycriptipn 9t the inv^ntiQn 
Before proceeding with a detailed description of 
the present invention it would be desirable to give a general 
description of the svibject invention particularly pointing 
cut the advantages of the system compared to the prior art. 

Briefly, as indicated, all fault^tree analysis is 
based on the concept that in many real time application 
environments there are certain system outputs which are of a 
greater concern to a system user than others. Inappropriate 
states or occiurrences of these system outputs are considered 
to be critical failures. Instead of attempting to insure the 
correctness of an entire design^ fault*tree analysis attends 
only to thes sal ct d conditions of greatest cone m. The 
basic method logy is to assume that the critical utput 
conditi tif referred to as the "top-level «e vent" has occurred and 
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th n to V r)c bac)cvards to determine what conditions^ if any, 
could have resulted in that top- level •event. 

Hardware fault-tree analysis (HFTA) was initially 
developed over many years, for ballistic missile programs to 
determine all possible paths which could result in an 
inadvertent adssile launch. It Is a well developed discipline 
and Is generally accepted to be the most rigorous of the 
hardware reliability analysis techniques. Zn any event, over 
the last few years several researchers have attempted to 
develop the software fault-tree analysis (SFTA) • All of 
these attempts are modeled on hardware fault-tree analysis 
and are limited to analysis of single safety related 
failures. As will be explained, the present apparatus and 
methods of the present invention consists of a fundamental 
modification to the methodology of both HFTA and SFTA which 
is followed by an integration of these modified techniques. 
Both HFTA and SFTA as conventionally applied are restricted 
to safety analysis of a single "loss event** • Through the 
subject inventions fundamental modification to these 
techniques, fault-tree analysis can be applied not only to 
single point safety failure but to critical system outputs in 
general. This refocus of the object of fault-tree analysis 
permits a generalized format for the expression of the output 
conditions which are allowed to be defined as the top-level- 
event. 

Thus, the present system integrated fault-tree 
analysis (SZFTAN) modifies conventional fault-tree analysis 
to permit a comprehensive and complex statement of €ach 
critical output to be evaluated. This is accomplished by the 
establishment of a stack of contradiction parameters which 
will be described in the text to follow. The second 
fundamental innovation performed by the present system and 
apparatus is the integration of the modified forms of KFTA 
and SFTA. As discussed above, a complete analysis of the 
critical failure potential of a design can only result from 
an understanding of all of the possible interactions between 
th system hardware and its c ntrol software. 
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ThuB, the present systeai accomplish s this goal by 
superianposlng the hardwar and software fault tr es onto each 
other. This super position is accomplished by automatically 
branching from the SFTA to the HFTA wherever hardware could 

S result In a critical system outcome* At the onset/ it is 
important to stress that the present systeai is applied with 
great value to the early conceptual level of system design « 
The conceptual level specification is entered into the 
analysis using ADA as a program design language* As one can 

10 ascertain, ADA is a programming language developed under the 
auspices of the United States Department of Defense (DOD) for 
the purpose of reducing software development and maintenance 
costs, especially for large coxustantly changing programs of 
long life times. 

15 ADA was designed during the periods from 1975 to 

1980 and it was specifically intended to support modem 
programming techniques such as structured programming, 
information hiding, abstract data types and concurrent- 
processing. The original motivation for the ADA development 

20 stemmed from military command and control applications, 
particularly for computers "in weapons, airplanes or other 
military equipment". Although these applications have some 
special requirements, such as real time processing, 
concurrenc^y and nonstandard Z/O, the requirements that 

25 emerged are suitable for a general purpose programming 
language. The design proceeded in that spirit and. as a 
result ADA is widely used in industrial business and 
university facilities as well as in the military. 

There are many texts which completely describe the 

30 ADA programming language. See for example Encyclopedia oj? 
gcmp^<??y Sgje^icft flffd Bnqjlnegyinq 2nd edition by A. Ralston et 
al« published by Van Nostrand Rheinhold Company (1983)* As 
will be further understood « there is no actual completed 
software design that is reqpiired as the system design flow 

35 ^art is substituted for software design at an early phase in 
th concept >s development. 

Similarly, an upper level bloclc diagram of the 
hardware concept is entered int the analysis at this arly 
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staga for composition of the hardvar fault tre . For the 
restricted set of critical system outputs, the present system 
is considerably more comprehensiv than currently available 
reliability analysis techniques. Its superiority resides in 
the systea^s degree of axuilytical completeness. Current 
software verification and validation techniques can find many 
errors but due to the path combinatorics problem can give no 
assurance that critical errors do not remain « The present 
system and apparatus does give this assurance. 

The path combinatorics problem is also a limitation 
on current hardware reliability and analysis techniques. 
FMECA, for example, is limited by the fundamental weakness of 
all forward failure prediction techniques in that it can 
evaluate the effect of only a small fraction of the possible 
component failure modality interaction scenarios. Predicting 
the effects of multiple failures and transient failures is 
very difficult and rarely attempted* Since the much more 
rigorous technique afforded by the present invention is • 
directed baclcwards into the system from the critical failures 
themselves, such dangerous gaps in the investigation are 
precluded. The most important advantages of the present 
.system however reside in its system integrated analysis 
approach. That is, not only does SIFTAN incorporate the 
individual power of HFTA and SFTA but it also has the unique 
capability of detecting all possible hardware-software 
critical failure interactions. 

An equally Important benefit of SZFTAN's Integrated 
approach is that since it is directed to investigate any 
possible cause by which actual system outputs are postulated 
to have occurred, it is equally sensitive to the detection of 
specification errors as it is to software coding or hardware 
implementation errors. When SIFTAN analysis is applied to a 
particular design level, it will certify that the design is 
critically faileafe or it will point out what design 
modifications are required to obtain this assurance. 
Following completion of the designated design modifications, 
rerunning SZFTAN analysis will certify that the design is now 
free f the potential for critical failur • This 
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certification however ifl restrict; d to the design 1 v 1 
analyzed and to all higher 1 vels of d sign abstraction. If 
an upper level system concept is certified critical failsafe, 
a critical failure may still result if that concept is 

5 Incorrectly implemented In the final design. It is, 
therefore^ necessary to reapply 8IPTAN analysis at each lover 
design level. It Is theoretically possible to abstain from 
SZFTAN analysis until the final design is complete since this 
final certification assures the entire design Is critical 

10 failsafe. This Is a very Inefficient course, however, since 
correction of any critical failure potential discovered by 
SIPTAN at this late stage may require major modifications to 
the entire system concept. 

By applying SZFTAM to the upper level trade-off 

X5 analysis and to each successive phase of a design, both the 
designer and the procuring agency or customer vlll 
continually be assured that all risk associated vlth the 
system under consideration has been accounted for and 
eliminated. As discussed above, SZFTAN can be applied 

20 manually to the upper level system concept or specification. 
If the system concept is represented in ADA, this can be 
combined vlth the critical failure list and the analysis 
begun. 

If the system cdncept is not yet at this level of 
25 definition, the system specification is flov * charted and 
phrased in ADA prior to initialization of the system 
analysis. A block diagram of the hardware concept for the 
system is utilized for the HFTA input. 

Zn order to perform SZFTAH on the completed design, 
2Q an automated analysis is required since hundreds or thousands 
of lines of embedded code and considerable hardware detail 
would be Involved in even a small system. The automated 
SZFTAN analysis tool performs an algorithmic parsing of the 
code which repsresents the final system design. This parsed 
25 output is then automatically searched for a specific set of 
pr gram instructions al ng th lines of . the SZFTAN 
contradlctl n search algorithm which will be ut lined below. 
Zn order to perform automat d SZFTAN analysis, it is 
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necessary to s lect single eysten design languag as a 
standard and to build the analysis tool around it. Since ADA 
is sandat d by DOD as the d sign languag standard it was 
selected as the appropriate language* 

The subject invention also can be employed 
utilizing other prograaming languages as will be clear to one 
skilled In the art. The potential benefits afforded by 
SZFTAM to software reusability are particularly important. 
Reusable components (RC*8) will now be able to be certified 
as free of critical failure. SIFTAN thus provides an 
acceptance criteria which fills a void left by current 
software analysis tools. By filling this void, SIFTAK 
provides a new and definitive metric for establishing the 
trust level .of reusable software. In doing so, SZFTAN 
defines and bounds what would otherwise be an open-ended 
testing requirement for reusable components. In a manner analogous to 

that currently used in the specification of standardised 
hardware components, SZFTAN can categorically certify that* 
each reusable software component conforms to certain 
specified behavior as long as other specified interface 
constraints are maintained. 

The immediate impact on the user's trust level in 
the software can tie gauged from a comparison of the SZFTAN 
certification format as compared to the current disclaimers 
of responsibility that are presently employed for reusable 
ADA. The potential software user will now be certain that 
the risk of mission critical failure due to a latent error in 
a reusable component has been eliminated. 

As one can understand, present software disclaimers 
as existing in the prior art indicate that the software and 
its documentation are provided "as is" and without any 
expressed or implied warranties whatsoever. The software is 
provided with the fact that no warranties as to performance, 
merchantability or fitness for a particular use exist. 

Zt is further indicated that because of the 
diversity of conditions and hardware under which the software 
may be used there is no warranty of f itn ss for a particular 
purpose. Thus, the user is advised to t st ths prior art 
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Boftvara thorougl)ly befora relying on it. Th us r must 
assxuB tha ntira riak and liability f using th software. 
Zn no event shall any parson or organisation be held 
responsible for any direct, indirect, consequential or 
inconsequential danages or lost profits* As one can 
ascertain, this is a standard prologue for reusable prior art 
ADA and is inherent in all prior art programming. - The 
potential software reuser in regard to the present system can 
be assured that there will be no errors in the integration of 
reusaOdle components which could result in a mission critical 
system failure* The SIFTAN certification will essentially 
indicate that the reusable software component is certified to 
be free of distinct failures while indicating what hardware 
and software interface constraints must be observed. Thus, 
the SIFTAN certification is inserted' as a structured comment 
field in each reusable component (Module, Package or 
Procedure) specification. 

As will be understood in the following technical* 
background section, SIFTAN analysis automatically traces a 
suspected critical path by working backwards along all 
relevant intercomponent interface linkages. If SIFTAN finds 
that the origin of a poasible critical path could be 
generated from the output of another reusable component, the 
tool will first examine the contcmt of the SIFTAN structured 
conment field found in the HC specification for that 
component. By doing so, SIFTAN may f ipd that the possibility 
of the suspect critical path has already been eliiainated by 
the results of a previous analysis. if this is the case, a 
SIFTAN analysis of the RC body is not required. 

SIFTAN analysis of the RC body will only take place 
if the existing .set of certifications found in the SIFTAN 
structure coBroent field is insufficient to rule out the 
- possibility that a critical failure path could originate in 
that RC. The additional certifications resulting from the 
analysis of the RC body, are then added to the set in the 
SIFTAN Structured comment field. The RC is thus returned to 
the r usable component library with a set of r liability 
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certifications that is enhanced over the set -that the RC 
possessed when it was taken ut f the library. 

Referring to Fig. 1| this is bri fly shown. 
Essentially, there is shown a reusable component 10 taken 
from ADA RC library. The additional 

certifications resulting from the analysis of the RC body are 
then added to the set in the 8ZFTAN structured comnent field 
via module 11 and then returned to the reusable component 
library 12 with a set of reliable certifications that is 
enhanced over the set that the RC possessed when it was taken 
out of the original library 10* Thus, the process is briefly 
shown in Fig. 1« 

Hence f as one will understand, with each individual 
application of SIFTAN analysis of an RC body, the likelihood 
increases that only a scan of Its SIFTAN structured comment 
field will be required in future SIFTAN analysis ot that RC* 
The entire set of integrated reusable ADA components that 
form the overall program is of course subjected to SIFTAN * 
analysis as a whole. The SIFTAN certifications that result 
from this overall analysis of the program are the ones that 
directly satisfy that the operationally defined "critical 
failure** outputs which initiated the path search cannot 
occur. 

The entire program composed of individual reusable 
components is thus prepared by its SIFTAN certification to be 
submitted to the ADA RC library 12 as a reusable component 
itself. SIFTAN therefore allows the evolution of 

increasingly larger units of reusable software through the 
continual enhancement of the set of critical failure-^free 
certifications applied to increasingly higher levels of 
functional abstraction* This process is shown in Fig. 2. 

In Fig. 2 there is shown a system module 14 which 
is operated in conjunction with a system. The system module 
14 in regard to its programming or structural formation is 
accessed from the ADA RC library 15. Based on the above, it 
is now enhanced in module 14 and returned to the ADA RC 
library 16 in the nhanced m de. Hence, the proc ss simply 
illustrated in Fig. 2 provides a disciplined method for 



WO«./«B0«7 PCT/USWB2B 

-16- 

pennlttlng increasingly larger units of reusable s ftware 
over time vhll objectiv ly insuring that th trust level of 
these larger cootponents are not compromised « The utilization 
of SZFTAN in combination with the widespread reuse of 
certified components will result in a complete solution to 
all aspects of the RC trust level problem. The likelihood 
that non-critical failures exist in an RC will be continually 
decreased over time through the collective experience of a 
broad community of users. Those failures, however, which a 
potential software user cannot afford to discover through use 
(i.e. critical failures) will be assured to be eliminated 
through the SZFTAN tool. 

SIFTAN is initialised with the critical output to 
be searched and its stack of contradiction parameters is 
Initialised with the conditions that are necessasry to make 
the critical output a fault condition. At each point in the 
trace-^back procedure, the SIFTAK tool determines the 
conditions that are necessary in order to reach the critical- 
output point and compares these conditions to the Stack of 
Contradiction Parameters. Xf a contradiction to a stack 
element is found tl&en the SIFTAN trace back stops for the 
path undor analysis. If no contradiction is found then 
SIFTAK adds the critical path condition to the contradiction 
stacdc. 

Any subsequent condition in the trace back that 
contradicts a * condition that was placed on the stack mean& 
that the path is blocked, i.e. it cannot be traversed through 
both conditions. Whenever a blocked path is encountered, the 
conditions that were placed on the contradiction stack, back 
to the last branch takeniare popped off the stack, only the 
conditions necessary to take the path to the critical output 
are analyzed at each step of the trace-back process. tOien 
all paths to the critical output have been traced and a 
contradiction to the stack found for each path then the 
program is certified free from the specified critical fault. 
Zt a path can b travers d with ut contradicting th stack 
then th critical fault path is identified and the possibl 
faul^ condi1:ion indicat d. 
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At any point where a determination of a variabl 
value depends on hardware inputs, these inputs are stated as 
fip cification of a r q[uired hardwar fault^tree analysis. 
When a path which requires analysis is too complex to be 
traced by SZFTAH within an assi9ned time period then SIFTAM 
indicates this fact by recoaaending that the code be 
simplified to. support better traceability and made more 
reliable by adding extra checks to block off critical paths 
into more localized areas. 

SBcetfics Dsacrlptlon of fche Operation of the Subiaet 

1. SIFTAN is initialized by user definition of a 
critical output condition. This will be a combination of 
events occurring simultaneous with a specified system output 
condition* This combination of events AND'ed with a system 
output condition is thereupon defined as the overall top- 
level-event of the SIFTAH analysis. The user-defined 
critical output condition can be defined with any combination- 
of AND*ed or OR*ed simultaneous events^ all of which are 
AHD'ed with the system output. For example, system output A 
occurring while either environmental condition B is false or 
environmental condition c is false and system configuration D 
is true" is a valid definition of a top -level -event. 

2. The system output segment of the top-level- 
event defined in Step 1 above becomes the Step 3 entry point 
into the system software. The other members of the set of 
top-level-event conditions are placed in the Stack of 
Contradiction Parameters'. 

3. SIFTAN searches the parsed system software and 
identifies the program statement which sets the system output 
segment of the top-level*event« 

4. The program structure (e.g. WHILE, IF-THEK or 
ELSE, CASE, RENDEZVOUS, SELECT) of which the program 
statement found in 3 is an element is then identified. 

5. A generic fault-tree template for the program 
structtire identified in 4 is retrieved from SIFTAN memory. 
This gen ric fault is particularized to identify which Inputs 
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t th pro9ram structure id ntified In 4 vill result in the 
program statem nt output found in 3. 

6. The particularised fault tree established in 5 
is then examined for the existence of two types of 
contradictions: Internal and External, 

a. Internal contradictions are composed of 
matheaatical contradictions 0^5 } or logical 
contradictions in\:emal to the fault tree of the program 
structure under consideration (e.g. a path vithin the fault 
tree which does not lead to the output identified in 3} • 

b. External contradictions are the logical or 
matheaatical contradictions between a fault-tree statement or 
an element within the Stack of Contradiction Parameters. 

7. If a contradiction is found in on^ input of a 
logical AND or all inputs of a logical OR, all paths which 
lead to those elements of the program structure fault tree 
are eliminated from further consideration outside of an HFTA. 
(REF. Step 9). 

8. All input states into the particular program 
structure fault tree which are not eliminated during the 
contradfction search steps 6 and 7 become new top-level -events and 
the process continues at Step 3. Examples of Steps s-8 for 
several comon AZ>A program structures ares 

Asaioronent statemmfc 

Variable^name Expression 
Determine values of variables in the expression that would 
result in the output variable being within the range that 
would lead to the critical event being traced^ i.e. they do 
net contradict stack elements. Add these values to the 
contradiction stack • 

Continue trace back looking for other assignaent statements 
that set the values of the variable used in the expression. 

IF condition "X- TOIEN-ELSE Stniefenye 

A. Event in THEK path«> Determine if condition "X«» FALSE 
prior to IF clause, i.e. place "X" FALSE condition in 
contradiction stack. 
OR 
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B. Event In ELSE path -> Dotamin if c nditi n "xn FALSE 
prior to IF clause, i.e. place "X" FALSE condition in 
contradiction stack » 

Continue search for all outputs that determine value of ''X**. 

C. CASg "Ytt si:rueture 

i« Event in WHEN «X*> path»> Deteraine if condition uy>X« 
TRUE prior to CASE clause i.e* place *"X* condition in 
contradiction stack. 

11, Event in WHEN OTHERS path«> Determine if all WHEN ^Y-XN" 
conditions FALSE prior to CASE clause, i.e* place "Y^Xl and 
yeX2 AND...YsYn "FALSE condition in contradiction stack. 

Continue search for all outputs that determine value of ^'V*. 

D. Loop Without Interaction Scheme fEXIT WHEN «X«>> Struetuye 
Determine if Event is output in any execution of loop prior- 
to EXIT transfer out of loop* 

1« Event In first execution of loop prior to exit statement 
>*> No contradiction to event execution. 

11* Event output only after (N>l}th execution of loop exit 
statement »> Determine if condition "X« - FALSE for N«l 
iterations of loop^ i»e. place *'X" « FALSE condition in 
contradiction stack and trace back through N^l iterations 
(sequentially or algorithmlcally as applicable) • 

E. FOR «x RAWGE* Lecp Structure 

Determine if Event is output in first or only in (N>l)th 
execution of loop 

Elaborate "^X*' to determine discrete range. I.e. Iteration count 

I. Event in any execution of FOR loop »> 

Determine if range of **X*' 'ls hot NULL prior to FOR clause. 

II. Event output only in (N>l)th execution of loop -»> 
Determine if •'X RANGE" > N-1. 
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F, WHII,E "X* i^oo strtietura 

Dottttnin if Ev nt is eutpttt in first er only in (N>l}th 
execution of loop 

i* Event in any execution of WHILE loop ■» 

Oeternine if condition "X" TBVS prior to WHZLE clause, i.e. 

place "X*' condition in contradiction stack. 

ii. Event output only in (H>l}th execution of IfHZLE loop «> 

Determine if condition "X" TBUZ after N-1 iterations of WHILE 

loop i.e. place "X" condition in contradiction stack and 

trace back through N-1 iterations (sequentially or 

algorithnically as applica]>le) . 

G. PROCEDORg Callg/Retiiima 

Event within a procedure => Place CALL parameter values that 
cause event execution in contradiction stack* 
Continue trace back through all possible callers with 
required call parameter values. 

9. In every relevant instance of external data input or of. 
output actuation found within the particularized program 
structure eault tree, an HFTX is automatically initiated. 
The identified state ot the input statement or output from 
the output actuation statement becomes the top-level -event of 
the HFCX. The HFTA terminates when all ii^uts to it are 
prime events of Icnown probability. 2he UFTX is accomplished 
by SIPTAN providing the appropriate series of prompts to the 
designer and the Boolean calculation of the resultant 
reliability. An example of this process is shown in Fig. 12. 

10. IF all paths leading to the critical output condition 
defined in (1) are blocked by contradictions and all HFTA 
outcomes are above a user assigned reliability threshold, the 
analysis is complete. The system is thus determined to be 
safe from- the critical failure defined in (1) . If a path 
which is not blocked by a contradiction, or an HFTA which is 
below the reliability threshold is found, the analysis is 
also complete. The system, howev r, is f und susc ptibl to 
the critical failure def in d in (1) . The sourc f this 
susc ptibility is identified by the SIPTAN analysis. 
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Following the reguir d revlsl n t th systea design, SZFTAK 
analysis is reinitiated at (1) t insure proper 
Implementation of the corrective action. 

Zt is further inportant to note and in 
consideration of steps .1 and 6b above that combinations of 
simultaneously occurring events in the Stack of Contradiction 
Parameters which are AND*ed together are analyzed . together « 
Separate analysis, however, is required for each OR'ed 
parameter in the contradiction stack. The requirement for 
this separate analysis of OR*ed parameters is illustrated in 
Fig. 14. Zf the analysis is not performed separately, a 
contradiction found in a path with respect to one parameter 
cannot, in and of itself, result in a conclusion of path 
blockage. This is because with respect to another parameter 
in the stack the path may allow an unblocked critical flow to 
the top-level»event« 

The fact that separate SIFTAN analysis with respect to each 
OR'ed parameter will provide complete coverage results from 
the fact that Boolean AND distributes over Boolean OR i.e«, A A 
(BUC ) - (AOB) U (AOP }• For the case shown in Fig. 14, 
8ZFTAN automatically performs the two required analyses: 
1. (V>10) r\ (X<S) 
2* (V>10) r\ (z^o) 

SIFTAH analysis is initiated by user definition of a critical 
system output. As discussed in the outline below this top- 
level-event can be specified in a highly comprehensive 
manner. 

For purposes of illustration three hypothetical and highly 
simplified SDI related examples of critical design failures 
are shown. 

Referring to Fig. 3, there will be given a system 
example. Essentially before describing Fig. 3, the system 
exampl to be describ d d picts a concept for alerting a 
laser satellite defens weapon control , platform to the fact 
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that a group f space based v apons r sensors .is under 
attack » A group of Ight satellit s sends status messages to 
tha satellite defense platform. The receiver on the 
satellite defense platform will permit up to four missing 
status messages and will still assume that this is due to 
non-hostility related failure of the transmitting satellites. 
However, if fever than four status messages are received, the 
satellite defense platfoana will assume that an attack is in 
progress and vill proceed to initiate laser effected defense 
all knovn space based assets lof the adversary. 

One of the critical failures associated with this 
concept for satellite defense is an "attack false alarm". 
That is, the satellite defense platform incorrectly concludes 
that fewer than four status messages have been received when 
in fact this is not the case. 

Referring to Fig. 3A, the Figure depicts this 
definition of the critical failure which is that-«a conclusion 
of attack is made even though there are greater than four 
active satellites transmitting." As one can see from Fig. 3 A, 
the attack indication is indicated by module 30. The output 
of module 30 goes into AMD gate 31 with another input of AND 
gate 31 obtained from module 32 which indicates that there 
are fewer than four active transmitters. The output, of AMD 
gate 31 is indicated by reference numeral 32 giving a false 
attack indication. 

The flow of the SIFTAM analysis is partly shown in 
Figs. 3B and 3C« As one can see from referring to these 
Figures, only the left most path is pursued as other paths 
are blocked by internal or external contradictions. 
Following the analysis to its conclusion finds that a power 
transient which occurs during the precise time that the 
receiver BIT (Built-Zn Tes^) was sampling for power stability 
could result in the critical failure defined. This problem 
is easily corrected by a restatement of the receiver BIT path 
criteria. 
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As Shown in Fig. 3B, AND gatd 35 is ass elated with 
module 37 which Indicates the TK£H PAKT CAUSED EVENT vhll 
the AND gate 36 is associated with module 38 which Indicates 
the ELSE PART CAUSED EVENT. The inputs to AND g<4te 35 
indicate that less than four signals were received via 
module 40 while the other input to AND gate 35 provides an 
attack indication via module 41. Zn a similar manner, AND 
gate 36 has one input from module 42 indicating that fewer 
than four signals were received and module 43 indicates a no 
attack indication. 

Thus, as one can see from Fig. 3C, the final 
emalysls results in the fact that there is an output OR gate 
50 which has its output coupled to an attack indication 
module 51 indicating that greater than four signals were 
received indicative of an attack indication. The OR gate 50 
is now associated with three AND gates 52, 53 and 54* With 
each AND gate indicating a specific clause which caused the 
event to occur. In this manner the output of AND gate 52 is. 
coupled to module 55 indicating that CLAUSE l" CAUSED THE 
EVENT. The output of AND gate 53 is coupled to module 56 
indicating THAT CLAUSE 2 CAUSED THE EVENT while the output of 
AND gate 54 is coupled to module 57 indicating THAT CLAUSE 3 
CAUSED THE EVENT. 

The inputs to the AND gates are shown in Fig. 3, 
and for example, the input to the three input AND gate 52 
indicates that the CONOZTIONAL TEST MAS THEN BETWEEN ZERO TO 
THREE SIGNALS RECEIVED which is indicated via module 60 which 
is also associated with the HFTA or hardware input. The 
second input to AND gate 52 indicates that the RECEIVER OP 
CONCERN PASSED THE BIT TEST and this Is shown in module 61. 
The third input to the AND gate 52 VIA module 62 indicates 
THAT GREATER THAN FOUR SIGNALS WERE RECEIVED Indicative of a 
true attack. As one can ascertain, each of the other AND 
gates as 53 and 54 have corresponding inputs indieated by the 
various associated modules. 

Hence, if any one of the AND gates provides the 
r qulslte output signal, th OR gate 50 which is an exclusiv 
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OR will Indicate that less than f ur signals v re rec ived 
and via nodule 51 indicating an attadc conditton. 

Referring to Fig* 4, there is shown a second system 
example. In this particular example it is assumed that one 
method of filtering out false ICBM launch indications in the 
IR (Infrared) domain is to automatically reject high 
intensity events limited to a single confined area on the 
ground. This is because an actual first strike would more 
likely be generated from more than a single launch site. A 
confined high intensity IR event is therefore deduced by the 
system as a non-hostility related fire or explosion. An 
adversary r however, assuming this type of false alarm 
filtering, may in fact intentionally malce use of it by 
coordination of a ballistic missile attack from a single 
launch site. A hypothetical counter^counter-measure against 
this strategy would be to coordinate a group of satellite 
sensors to examine the suspected single launch site with fine 
resolution from various angles. For a very short time 
derivative these satellites would focus on the single launch 
site with a very fine IR intensity resolution* 

If an insufficient intensity delta is detected 
during this short time derivative, the satellite sensors are ' 
reformatted to the normal range. A critical failure in this 
example 2 as indicated in Fig. 4, is again defined as a false 
attack indication. A non*anticipated path which leads tc 
this critical failure is shown in Pig. 4B» During-' the very 
short time derivative that the sensor alarms are set to a- 
fine resolution, a higher priority interrupt occurs taking 
the system out of the single launch site analysis mode. This 
new detection algorithm asstuaes that the sensors are set for 
normal IR resolution. 

However, reformatting out of the fine resolutions - 
set previously was prevented by the interrupt. All 
satellites in the new scenario therefore send an alarm 
indication even though they have not been presented with an 
IR stimulus exceeding a normal range. As shown in Fig. 4B, 
this cas f ritical failur potential is an xample of a 
tiypical problem which ccurs in all larg design efforts. 
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Two different nodules are written by tw different gr ups 
each assuming that proper data formatting is being done by 
someone else. SIFTAN overcomes this difficulty by working 
backwards from nodule B (73} and discovering any possible 
path by which unformatted* input could enter that module. A 
fundamental element of the heuristic power of SIFTAN ia that 
it does not assume that anyone is doing their job. 

Thus, as one can ascertain from Fig» 4A, the normal 
ZR Resolution Processing is indicated by module 60 whose 
output is coupled to the Event Driven Interrupt to Single 
Launch Site Analysis. This is indicated by module 61* The 
output of module 61 is coupled to module 62 which is a Fon&at 
to a Fine IR Resolution for the Time Derivative. The output 
of module 62 goes to the decision module 63 indicative of an 
Over Threshold decision. Hence, if module 63 determines an 
over threshold (YES), it provides an attack indication 
indicative of module 65. Zf it determines that there is not 
an over threshold (NO) then it proceeds to Reformat the IR. 
Range for Kormal Processing as Indicated by module 64 and the 
above sequence is repeated. As one can see from Pig. 4B, ths 
same reference numerals have been indicated to describe the 
same decision making processes as in Fig. 4A. In any event, 
as one can ascertain, the coupling between the Reformat IR 
Range module 64 to the Normal IR Resolution Processing module 
60 is implemented by the modules as 70 and 71 Miich indicate 
that a High Priority Event Driven Interrupt occurred to set 
the system to normal resolution processing. 

The output of this module goes to module 71 which 
indicates HUltiple Sensor Over Threshold which is an Attack 
Indication with High Priority* As indicated and is shown by 
modules 72 and 73, module A assumes reformatting in module B. 
This information is sent to module 73 which then indicates 
that module B assumes reformatting in module A. Thus, as 
shown in Pig. 4B, an unanticipated path which leads to the 
critical failure is indicated. 

Hence, during the very short time derivative that 
th sensor alarms ar set to fine resolution, higher pri rity 
int rrupt occurs taking the system out f the single launch 
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sit. analyais mod • This nsv d tection algoritluB assim s 
that the sensor ar set to nornal ZR resolution « Thus, as 
shown in Fig. 4B, this case of critical failure potential is 
an exanple of a typical problem which occurs. 

Referring now to Fig. SA to Fig. 5F, there is 
illustrated another system example which is example 3. The 
system example 3 as for example shown in Fig« SA shorn a 
concept for a nuclear reactor core coolant flow rate and 
failure alarm. This concept is expressed in ADA. A critical 
failure is defined as an average coolant flow rate of less 
than 98 which is not accompanied by a STATUS » AZARH, A 
system example 3 as for example indicated in Tig. SB shows 
this initialization of the SIFTMf analysis. 

Figs. 5C through 5F show the 8ZFTAN analysis 
itself. As shown in Fig. 5F, the coding for the alert 
indication is found to present the critical failure path. In 
system example 3 Fig. SA REVISED this failure is removed from 
the code and Fig. 5F REVISED shows that a SIFTAN analysis of. 
the corrected software will now result in fail^^safe 
certification » Each illustrates both the path combinatorics 
problem and the power of the new approach to overcome that 
problem. Zn all three examples, critical failure would 
elicit itself only under circumstances that might easily be 
unanticipated and undetected by conventional design analysis 
technigaes. Critical failures of examples 1 and 2 would 
occur if a particular chain of events occurred during a very 
short and specified time interval. . 

Critical failure of example 3 would only occur if 
the coolant flow rate was found to be in the very limited 
alert range of 9S to 100. Due to SIFTAN 's tinlgue critical 
failure focus and hardware/ softweore scope, it automatically 
detects the possibility of all these types of conditions. 

In regard to the ^ above, it is immediately 
ascertained that the system program example as depicted in 
Fig. 3 was taken from the actual operation and control 
softwar utilized for a d fens system application. This 
package label d Acc ss Semaphore is used to control program 
-flow to gain entry into a data base. A SIFTAN analysis was 
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performed on this rendezvous program structure to deterain 
if the critical failur defined aa "reading from the data 
bas while another program is writing into it* could occur« 

This package was originally designed for an 
application which only one task at a time could request 
access to write into the data base. When used in this 
original environment, no errors were reported. It was not 
known to its designers, however, that another critical 
failure could arise if the package %ra8 reused in another 
application where multiple, simultaneous, write requests were 
possible. SIFTAK analysis of the package discovered this 
latent critical failure. 

Zn any event, as one can ascertain, the following 
program examples are given to familiarize one with the 
problem as well as the solu1:ion to the same concerning the 
SZFTAN analysis of the Access Semaphore as described above. 

The following package is used to control program 
flow to gate entry into a database. The procedure for using 
this program is as follows: 

For a task that desires to read from the database: 

ACCESS^SEKAPHOIUB. DB_OB_READJREQUBST ; 
<code that reads the database>; 
ACCES$_S£KAPHORE . DB_SEAO_ItELEASE ; 

For a task that desires to write into the database: 

ACCESS_SEMAPHORE • DB_WRITE_REQUEST t 
<code that writes into the database>; 
ACCESS_SEMAPHOR£. DB_WRITE_R£LEA5E; 

package body ACCESS_SEKAPHORB_PX6 is 

task body ACCBSS.SBKAPBORE is 

type ACCESS_TYPE is (OPEN, LOCKED) I 

DB USERS t integer t « 0; 
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DB_ACCESS : ACCSSS^TYPB S- OPEN; 

be9in 

loop 



select 

when DB_ACCESS - OPEN -> 
accept: DB_REAO_IlZQUEST do 

OBJJSSStS t - OBJdSERS -i- 1; 
end OBJRSAD_ltEfl!0ZSTy 

or 

imen SBJlcaSS " OPEN and DB_t7SERS>0»> 
accept OB_read_BElEASE do 

DBJUSERS :-DB_USERS-l; 
end DB_fiEADJlSLEASE: 

or 

when DB_USERS ■> 0 •» 
accept DBJHRZTE.REQUSST do 

DB_ACCBSS X • UOCtaSDl 
end DBJNRZTEJREQUEST; 

or 

Vhen DB_ACCESS * LOCKED «> 
accept OB_HRITE_SEL£ASE do 

DB_ACCESS :>=OPEN; 
end DBJHRZTE.REIJSASE} 

end select 



25 end loop? 

end ACCESS_SSHAPHORE; ; 
end ACCESS_SE1(APH0SE_PKG; 

A SIFTAN analysis of the above package was 
performed in rder to determine i£ the critical failure of 
sa "Heading froa th database while another prograa i writing 
into it'' could occur. SIFTAN detect d that a path to this 
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critical failure doea xiat it th package la utilized In 

an application vher there la mor than one writer to the 
database. In the application f r which this package was 
designed, only one writer was Involved and this latent 
critical path wa» therefore not previously discovered. 

In order to allow its general reuse in multi-writer 
applications, the Access Semaphore package was nodifled as 
shown below. Re-running SIFTAN analysis on the nodifled code 
certifies that it is now free of latent critical error. 

package body ACCESS_S£KAPHORS_PXG is 

task body ACCESS_SEKAPHORE is 

OB_READERS : Integer : 0; 
DB_inRXTERS : Integer : » 0 

begin 

loop 

select 

when DB^WRITERS « 0 - > 
accept DB_REAO_R£QU£ST do 

DB_READERS : - DB_R£AOERS ^1 
end DB_REA0JREQUE8T| 

or 

when DB_2^0£RS > 0 »> 
accept DB_READ_RELEASE do 

DB_R£ADE2^ : « DB^READERS - 1; 
end DBJREAD^RELEASE; 

or 

when DB_R£ADERS « 0 -> 
accept 0B_imiTB_REQt7EST do 

DB_«RITERS : - DB^HRITERS ^ 1| 
end DB_WRITB_REQUEST; 

or 

when DB WRITERS > 0 -> 
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ace pt DB_t«RZTS_RZLBASE do 

DB_WKZTERS i • OB_KRZTERS - 1| 
end DBJHRZTS^lUSLSASEl 

•nd s«l«cl:/ 

S end loop; 

end ACCESS_8SMAPH0IiE; 
end ACCESS_SSIAP1K»S_PXG| 

Referring to Pig. 6, there Is shoim an example of the 
overall structure of the SIFTAN method. One will see the position 
10 of the stack of contradiction parameters and the superposition of 
the •ofttMre fault tree with the hardware fault trees ( HFTA ). 

Pig. 6 .is utilized 
to shov ae indicated a typical SIFTAN analysis and this contains 
eoHton program constructs; CASE, HHILE. and IF THER OR ELSE. 
IS Pigure 7 shows a flow chart indicating 

contradiction in software which prevents a critical Mtput. 

,Plgure 8 8ho«rs the contradiction in software vhlch 
prevents a critical output but hardware failure overrides 
that contradiction as shown by the shaded line portions of 
20 Pig. S as conpared to Pig. 7. 

Pigure 9 shows no contradiction in software whereby 
the 8IPTAN systea traces the critical failure "to the 
environnent indicated by shaded aodulea. Pig. 10 shows no 
contradiction in the software found within the aTlowed analysis 
25 time. It is noted that the system w.IlT Identify the causes of 
all conditions as exemplified for example in Figs. 9 and 10. 

Pigure 11 shows a condition where SIFTAN encounters 
an unanalyzable structure while Fig. 12 as Indicated traces 
the probability of each event to provide complete hardware 
30 analysis. 

Figure 13 Indicates the various possible outcomes which 
can occur In the SIFTAN system enabling one to analyze safe and 
unsaf conditions. 
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Pigur« U is a slBpl block diagram shoving the 
requlreBents for separat analysis f Or»ed parameters in the 
contradiction stack as employed by the SIPTAH syst a. 

AS one will understand, the above system is 

5 intended to coBplenent conventional hardware and software 
reliability assurance approaches. Because of their diffuse 
concern with correct operation of all systea outputs, the 
existing techniques can find aany design "bugs" but cannot 
give any assurance that nuaerous errors do not reaaln. Due 

10 to Its focus on critical failures, the SIFTAH system can give 
a much stronger assurance of freedoa from critical 
specification error as well as freedoa from critical software 
error and provide systea reconfiguration hardware coverage 
completeness. Hhile the above-noted systea and aethods are 
intended for application to all design levels, the system 
analysis is particularly cost effective when applied to an 
upper level systea architectural concept or specification. 
Detection of iaportant latent design errors at this early 
stage of design avoids a auch acre expensive correction at a 

20 later stage in systea developaent, testing or deployaent. 

The benefit of the system application to the upper 
level systea specification is clearly seen with regard to 
integrated systeas of the type envisioned for present and 
future generation digital avionics. If two formerly modular 

2S components each have 10^® paths through their respective 
software, their integrated combination could have as aany as 
lo3* paths. Therefore, unless an advanced systea analysis 
technique is employed as for example the one described above, 
latent software failure when dealing with future integrated 

30 systeas will becoae even acre serious than it is today. 

In addition, the SIFTAM systea can indicate the 
appropriate iiaits on systea integration, it thus assists in 
the determination of how systea integration can best be 
accomplished so that one does not end up specifying the 

35 design of a system which is organized in a fashion that is 
too complex t ev r be reliably deployed. SIFTAH can 
acc mplish all of these goals in a highly cost effective 
aanner thr ugh analysis of the upper lev I system cone pt r 
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sp cification. Th potential applicatl ns of th above- 
describ d syst m ar numerous and Include reliability 
Insurance for all mission critical software driven syateaa on 
both the specification and implementation levels, the 
certification of the trust level of reusable softvare, the 
safe development and deployment of large scale digital 
systems, the certification of digital flight control systems ♦ 
The system provides minimxam cost fault tolerance for advanced 
digital systems and provides improved testability through the 
reduction of built-in test falsa alarms and unverified 
failures. The systea further creates the provision of a new 
evaluation metric which clearly limits the cost and risk 
Involved in new system acquisition or existing system 
modification* There are many advantages of the system as one 
can immediately ascertain from the above-noted specification 
as for example detemnined by the claims appended hereto. 
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1 Claim ; 

!• A method of performing integrated fault*tree 
analysis on a software controlled system^ of the type 
employing hardware under the control of programmed 
software comprising the steps of: 
S predicting a critical system output 

condition manifesting a top-level-event^ 

determining from that predicted condition 
a set of prior system conditions which caused 
said event, 

10 modifying the system response upon 

detection of an unblocked path to said event 
according to said determined set of prior system 
conditions^ 

2. The method according to Claim 1, wherein the 
step of determining includes tracking backward 
operation from said top-level-event to a first 
condition prior to said event and then to the next 

5 condition prior to said first condition and so on 

until all conditions in a descending order have been 
determined. 

3. The method according to Claim 2, wherein the 
step of determining in descending order includes the 
Step of superimposing hardware and software fault 
trees onto each other by branching from software to a 

5 specified hardware fault tree analysis wherever a 

specific hardware output could assume the function of 
said prior condition, and initializing said hardware 
fault tree analysis with the specific parameters of 
said hardware output prior condition. 

4« The method according to Claim 1^ wherein the 
step of predicting said top-level-event includes: 
forming a system design flow chart 
employing a program design language and using 
5 said design flow chart to predict said 

top-level-event by providing a software fault 
tree. 



wo 89/03087 PCr/US88/B3282 

-34* 

5. The method according to Claim 4/ wherein 
aaid step o£ predicting said top-level-event further 
includes forming an upper level block diagram of the . 
hardware configuration to provide a hardware fault 

5 tree and predicting said top*level-event by emplo/ing 

both said hardware and software trees. 

6. The method according to Claim 4, wherein 
said program design language is ADA. 

7. The method according to Claim 1, wherein the 
step of determining said prior system condition 
includes the step of; 

algorithnically parsing a code indicative 
5 of final system design and 

searching said parsed code for a specified 
set of program formats according to a given 
contradiction search algorithm. 
8« The method according to Claim 2, wherein the 
step of predicting said critical system output 
* condition includes: 

initialising a critical system output to 
5 be searched, 

obtaining a Stack of Contradiction 
Parameters indicative of conditions necessary to 
make said critical output a fault condition, and 
then the step of determining the 
10 possibility of said set of prior conditions by 

comparing said conditions to said stack of 
contradiction parameters to determine if any 
contradictions exist between said prior 
conditions and any elements in said stack, and 
15 then the further step of determining the 

possibility of said set of prior conditions 
through examination of each prior condition 
itself for logical contradictions internal to 
said set of prior conditions without respect to 
20 the status ot contraditl n param ters. 
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9. The method according to Claim 2, further 
including th step of certifying said modification 
through reapplication of the analysis according t 
claims 1 and 2, 

10, A method', of performing an integrated 
fault-tree analysis on a digital software controlled 
system of the type employing hardware under control of 
programmed software comprising the steps of: 

5 defining a critical system output 

condition specifying a top-level-system events 

forming a set of contradiction parameters 
indicative of other top^level-system conditions, 
parsing the system software for a program 
10 statement which sets the defined top level 

system events 

retrieving a generic fault-tree template 
for said program statement to identify which 
inputs to said program statement sets said 
15 top-level-event, 

examining said fault tree for 
contradictions according to said set of formed 
contradiction parameters to. determine which 
inputs do not lead to said top-level-event, and 
20 which inputs do lead to said top-level-event, 

eliminating all inputs found which do not 
lead to said event, 

replacing all inputs which lead to said 
event for defining a new top-level-event and 
25 continuing said steps commencing with said step 

of parsing the system software until all inputs 
are eliminated « 

11« The method according to Claim 10, wherein 
the step of examining said fault tree includes the 
steps of determining two types of contradictions with 
a first type being internal contradictions indicative* 
5 of paths within said fault tree which do not lead to 
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saLd pcogram statement and with the second being 
external contcadlctlons indicative of a discrepancy 
between a fault tree statement and an element in said 
stack of contradiction parameters. 

12. The 'method according to Claim 10, wherein 
the step of deflniAg said critical output condition 
includes ANDing a combination of system events with a 
system output condition Indicative of said 

5 top-level-event. 

13. The method according to Claim 10, further 
including the steps of revising said system design 
when all paths are not eliminated and then 
Implementidg the steps of Claim 10 after said revision. 

14. The method according to Claijn 10, further 
including the step of initiating a hardware fault-tree 
analysis each time said retrieved generic fault tree 
is examined for contradictions which depend on 

5 hardware inputs and employing said new top-level -event 
for said hardware fault-tree analysis. 

15. The method according to Claim 14, including 
the step of terminating said hardware fault-tree 
analysis when all inputs are prime events of known 
probability. 

16. The method according to Claim 15, wherein 
said known probability is calculated based on an 
assigned reliability threshold. 

17. The method according to Claim 10, wherein 
the step of retrieving said generic fault-tree 
template includes storing a plurality of said 
templates in memory and accessing said memory for 

S retrieving one of said stored plurality of templates. 

18. The method according to Claim 10, wherein 
the step of examining includes AMDing together 
combinations of simultaneously occurring events in 
saiid stack of contradiction parameters, and analyzing 

5 said AND'ed combinations togethec# 
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Ofting other param ters in said stack with 
otMer simultane usly occurring' events, and 

separately analyzing said OR'ed 
combinations apart from said AND'ed combinations, 

19. The method according to Claim 10, wherein 
said digital software conbrolled system is a digital 
defense electronic system. 

20. The method according to Claim 10, wherein 
said digital software controlled system is a digital 
automatic flight control system. 

21 « The method according to claim 8 further 
including the step of terminating the trace-back of 
prior conditions upon detection of either of the two 
types of said contradictions. 

22. The method according to claim 8 further 
including the steps of adding said prior conditions to 
the stack of contradiction parameters upon detection 
of neither of the two types of said contradictions and 

5 continuing the trace back according to claim 2. 

23. The method according to claim 8 wherein, 
upon indication that a path to said top-level-event 
exists completely through the software without being 
blocked by one of the two types of said 

5 contradictions, an output is generated indicating that 

the top«level-event can occur, and the further step of 
outputting an indication of the location in the 
software where the said one blocked path resides in 
order to facilitate corrective modification of the 

10 design under analysis » 
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TYPE STATUS IS (SAFE, ALERT, ALARM): 
PROCEDURE SAMPLE_COOLANT__FLOW_RATE (STATUS OUT) 
BEGIN 

STATUS: = SAFE; 

COUNT :=0 ; 

SUM:=0; 

MEAN:=Oi 

WHILE STATUS /sALARM 
LOOP 

WHILE COUNT <30 
LOOP 

FIG, 5 A (SAMPLE); 

SUM:«SUM + SAMPLE; 
COUNT: sCOUNT + 1; 
END LOOP 
COUNT: =0 
• MEAN_FLOW:aSUM/30 
CASE MEAN_FLOW IS 

WHEN> =1008 > STATUS: sSAFE; 
SUM:=0; 

WHEN<XOO AND>= 98 => STATUS: =ALERTi 
WHEN< 98 => STATUS :sALARM J 

END CASE; 
END LOOP; 
END SAMPLE_COOLANT_FLOW_RATE ; 



FALSE SAFE INDICATION 



FIG. 5B 




STATUS 


:= SAFE 




r 


STATUS t sSAFE 



1 



SAMPLE <98 



IMTIAUZATION 
ANALYSIS 



f 



r 

STACK OF 
CONTRADICTION 
PARAMETERS 



wo 89/03087 



7/19 



PCr/US8^/03282 



FIG. 5A 

CREVISED) 

TYPE STATUS IS (SAFE, ALERT, ALARM): 

PROCEDURE SAMPLE_COOLANT_FLOW_RATE (STATUS OUT) 

BEGIN 

STATUS := SAFE; 
COUNT: sO ; 
SUM:sO; 
MEAN:aO; 

WHILE STATUS /«ALAFM 
LOOP 

WHILE COUNT < 30* 
LOOP 

GET (SAMPLE); 
SUM; = SUM * SAMPLE; 
COUNT: -COUNT + 1; 
END LOOP 
COUNT: =0 

MEAN__FLOW ; sSUM/ 30 
SUM: =0 ; 

CASE MEAN_FLOW IS 

WHEN >= 100 = > STATUS := SAFE; 
WHEN < 100 AND> = 98 = > STATUS : sALERT ; 
WHEN < 98 a > STATUS :=ALARM; 
END CASE; 
END LOOP; 
END SAMPLE COOLANT__rLOW_RATE ; 
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